This invention generally relates to transaction performance monitoring; more particularly, the invention aims at measuring response time of transactions tracked across asynchronous flows in a Java (Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates) 2 Enterprise Edition (J2EE) application server.
In a production environment it is difficult to monitor J2EE application servers because of the debugging constraint problems. In this case it is not possible to use debugging and profiling tools and the most common technique to perform a deeper problem determination apart from browsing log and trace files is to record processing time in each of the components of the application server during a request to that application.
Currently available tools can collect transaction processing time and store in log or trace files for later retrieval and analysis or can send it to protocol agents such as an Application Response Measurement (ARM) (ARM is a trademark of ARM Ltd.) agent which is developed using an application programming interface (API) allowing to track resource consumption by a transaction when several elements in a network are contributing towards the completion of the transaction.
As a transaction flows through the system, these tools include additional information so that the log records from each component can be correlated, building up a complete picture of that transaction. The result provides processing time in each component, as in the following example in which processing time is provided for each software component participating in the completion of one transaction:
 HTTP request/trade/scenario - - - > 172 msServlet/trade/scenario - - - > 130 msEJB TradeEJB.getAccountData - - - > 38 msJDBC select - - - > 7 ms
The problem with such a solution is that it works only when the transaction within the application is a synchronous flow of calls among any number of components and or applications such as database servers, resource connectors, etc.
There is thus a need to collect processing time for a transaction when the application calls are made across asynchronous components. There is need for correlating the information collected when the application calls are made across asynchronous components like Java Message Service (JMS) resources for sending or receiving messages or when different applications perform independent read/write operations to/from an external data source or when there is the need to propagate a correlation information among different application components.
Known solutions to solve such kind of problems do not completely solve them and/or require to manually hard-code into the application the code that takes care of managing such correlation information. For example, in case of asynchronous transactions based on JMS queues, a typical way to solve this problem is to directly insert into the JMS message an additional parameter containing a correlator token. Such intrusive solution requires to write some custom code to be added to the applications that have to share the correlation information which is not possible when debugging applications operating in production mode and which cannot be modified.
Other solutions are based on on-the-fly instrumenting the application when it is being loaded into the runtime environment and intercepting specific method invocations corresponding to the start/completion of a transaction. But also such solution does not automatically take case of propagating a correlation information among different processes, both synchronous and asynchronous.
The US patent application published under the number US 2005/0039171 under the title “USING INTERCEPTORS AND OUT-OF-BAND DATA TO MONITOR THE PERFORMANCE OF JAVA 2 ENTERPRISE EDITION (J2EE) APPLICATIONS” discloses a runtime bytecode instrumentation of the application classes to locate static code points (always derived by a top level servlet invocation) where a transaction may occur. This prior art solution avoids modifying code source of applications running on a JVM application server, but it only supports transaction based on a pre-defined ‘parent child hierarchy’ which is static, meaning that the transaction flow is synchronous.
There is thus a need for a method to allow tracking of processing time of a transaction based on execution of a synchronous or asynchronous process flow.